A software container is an instance of a user-space running an application within the operating system (OS) of a host device (e.g., a server). Software containers enable operating-system-level virtualization in which the OS kernel allows the existence of multiple isolated software containers.
A software container (or a container) provides an executable environment with a complete filesystem. The filesystem may contain code, runtime, system tools, system libraries, and so on. That is, execution of a software container can be the same regardless of the underlying infrastructure. A Docker is one popular existing platform for creating, migrating, managing, and deploying software containers.
A software container, unlike a virtual machine, does not require or include a separate operating system. Rather, the container relies on the kernel's functionality and uses hardware resources (CPU, memory, I/O, network, etc.) and separate namespaces to isolate the application's view of the operating system. A software container can access the OS kernel's virtualization features either directly or indirectly. For example, Linux kernel can be accessed directly using the libcontainer library or indirectly using the libvirt service.
As demonstrated in FIG. 1, a number of software containers (i.e., the app containers 110-1 through 110-n, hereinafter referred to individually as a container 110, merely for simplicity purposes) can access and share the same OS kernel 120. However, each container 110 can be constrained to only use a defined amount of hardware resources (e.g., CPU, memory, etc.) in the underlying hardware layer 130. Thus, using software containers, hardware resources can be isolated, services can be restricted, and processes can be provisioned to have an almost completely private view of the operating system with their own process ID space, file system structure, and network interfaces.
FIG. 2 illustrates a typical structure of a software container 200. The software container 200 includes a base image 210 and a container layer 220. The base image 210 includes one or more image layers 215-1 through 215-q (hereinafter referred to individually as a layer 215 and collectively as layers 215, merely for simplicity purposes). The layers 215 are read-only layers that represent filesystem differences. That is, the layers 215 are stacked on top of each other to form a base for the container's 200 root filesystem. The layers 215 are read only, and each layer 215 is identified by a randomly generated identifier number of a checksum computed using a hash function. All layers 215 and the base image 210 are collectively referred to a “container image”).
The base image 210 (and its layers 215) can be shared across different software containers. Thus, only the container layer 220 differentiates between one software container and another. The container layer 220 is a readable and writable layer where all data written to the software container 200 is saved in the container layer 220. When the software container 200 is deleted, the writable container layer 220 is also deleted, and the base image 210 remains unchanged. As such, the software container 200 and other software containers (not shown) can share access to the same base image 210, where each software container has its own data state. In the example demonstrated in FIG. 2, the software container 200 is a Docker container (e.g., compliant with the Docker platform).
The popularity of software containers has been increased due to the easy integration with cloud-computing platform (e.g., Amazon® Web Services, Google® Cloud Platform, Microsoft® Azure, etc.). On such platforms, service providers can offer operating systems to run services and applications. With that said, the increasing reliance on software containers increases the need for secured execution.
Container images are typically uploaded and stored in image registries that may or may not be managed by an organization. Further, the base images are used across many container images. As such, base images can be developed and uploaded to image registries by programmers who are associated with the organization seeking to use the image. Therefore, hackers can take advantage of program images to include malicious code. Thus, such images can be vulnerable when integrated in a software container. Such malicious code may carry any type of malware including, for example, computer viruses, worms, Trojan horses, ransomware, spyware, adware, scareware, and the like. Further, such malicious code may be a source for an ATP attack or a distributed denial of service (DDoS) attack when a software container is executed with an infected or malicious image.
To limit the risk associated with container images stored in registries, serval security and/or auditing processes can be performed prior to uploading a container image in a register. However, such processes are very limited in the type of vulnerabilities that they can check. Further, a container image determined to be safe can be later modified by a hacker (or an innocent programmer) to include code that can harm the execution environment.
Typically, a software container (and, thus, each application) can be secured separately from other software containers (and applications) during runtime execution. Thus, one software container cannot access resources of other software containers. However, the isolation of software containers cannot prevent the execution of malicious code. Malicious activity by software containers can occur through exploitation of legitimate programs or services in a container and improper configuration. Improper configuration may result in, for example, privilege escalations. Detection of such vulnerabilities occurs only at runtime, i.e., during the execution of the software containers.
Existing security solutions are not designed to detect vulnerabilities in images of software containers. Specifically, images have a specific structure that cannot be processed by existing security solutions. Further, existing solutions cannot determine or predict how the container image (being a static file) would behave when it is being executed. For example, a conventional antivirus tool cannot scan container images to detect, for example, if an executable process has been modified. As another example, an antivirus tool cannot determine a system call that a process in a container image would trigger when the process is executed.
As another example, exploitation of legitimate programs may include utilization of named objects created by such programs to perform malicious activity. Typically, a named object can be used for inter-process communication, process synchronization, and the like. Malware, for example, can be programmed to preemptively create a named object before a legitimate program could create one. The malware can exploit the created object to propagate malicious code. Detection of such vulnerabilities occur at runtime only, i.e., during the execution of the software containers.
It would therefore be therefore advantageous to provide a solution that would secure the execution of software containers.